1 June 1997: Add Appendix S.
1 June 1997: Activate links to Images 43-107.

31 May 1997
Source: William H. Payne

Sandia National Laboratories

Albuquerque. New Mexico 87185

Technical Library
(505) 844-4233

June 22, 1994

    Dear Mr. Shope:

This is in reply to your recent request for the following report number(s):

    SAND91-2201 "Data Authenticator for the Deployable Seismic
                 Verification System" by William H. Payne

[ ] The information you requested is enclosed.

[ ] We regret we are unable to comply with your request. Please order from:

> [ ] | National Tech. Info. Serv. | [ ] | GovernmentPrinting Office
> | U.S. Dept. of Commerce 5285 Port Royal Rd. Springfield, VA 22161 (703)487-4650 |  | Receiving Branch (Attn: NRC Stock) 8610 Cherry Lane Laurel, MD 20707

[ ] The journal article/conference paper you requested is available through your public or university library.

[X] The report you requested is not releasable.

> [ ] Report has distribution limitations and is not available outside of Sandia National Laboratories.

> [ ] Report has not been published.

> [ ] We have no record of the requested report in our collection.

> [ ] Report is out of print and will not be reissued.

[ ]We need a letter of justfication or need-to-know before the report can be released.

[ ]Report cannot be sufficiently identified from the information furnished. Further identification is requested.

Comments:

[Note: "Offical Use Only" appears on all pages of the 185-page report; omitted post page 1.]

[1]

OFFICIAL USE ONLY

SANDIA REPORT

SAND91--2201 • UC--706
Official Use Only
Originator Controlled
Printed June 19 1992

## Data Authenticator for the Deployable
Seismic Verification System

William H. Payne

Prepared by
Sandia National Laboratories
Albuquerque, New Mexico 87185 and Livermore, Calitornia 94550
for the United States Department of Energy
under Contract DE-AC04-76DP00789

OFFICIAL USE ONLY

Contains information which may be exempt from public release
under the Freedom of Information Act (5 USC 552), exemption
number(s) 3 . Approval by the Department ot Energy prior to public
release is required.

Originator: Paul A. Stokes Date: 4/28/92

DESTRUCTION NOTICE

Destroy by any method that will prevent disclsoure of contents or
reconstruction ot the document. (See Sandia National Laboratories
Instructions (SLI) 1008-4,5).

SF 2900Q(8-81)

OFFICIAL USE ONLY

[2]

Issued by Sandia National Laboratories, operated for the United States Department of Energy by Sandia Corporation.

NOTICE: This report was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor any agency thereof, nor any of their employees, nor any of their contractors, subcontractors, or their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government, any agency thereof or any of their contractors or subcontractors. The views and opinions expressed herein do not necessarily state or reflect those of the United States Government, any agency thereof or any of their contractors.

[3]

SAND91--2201
Official Use Only
Originator Controlled Printed
June 1992

Distribution
Category UC--706

## Data Authenticator for the Deployable
Seismic Verification System

William H. Payne
Verification Systems and Technology Department IV
Sandia National Laboratories
Albuquerque, NM 87185

### Abstract

Data authentication is the process of computing a keyed checksum designed to ensure that a frame of data has not been altered after it has left a transmitter. The Deployable Seismic Verification System data authenticator implements a sensitive shift register algorithm in hardware. Key management and loading are done with an 80C31 microcontroller. The data authenticator is housed in a cast-aluminum TEMPEST enclosure. Interface cards connect the data authenticator to the PC/XT, VME, and authenticator buses. The data authenticator costs approximately $1500; it processes about 20K bytes per second, draws approximately 200 milliamperes, and occupies about 5-3/8 inches diameter by 10-1/2 inches of space.

OFFICIAL USE ONLY Contains information which may be exempt from public release under the Freedom of Information Act (5 USC 552), exemption number(s) 3. Approval by the Department of Energy prior to public release is required. Originator: Paul A. Stokes Date: 4/28/92

[4]

### Acknowledgments

The author thanks the following people who gave so much of their time and effort to this project:

G. D. Blanchard for drafting, casting, and machining the TEMPEST container; Douglas Downen for providing the DOE-NSA interface; H. B. Durham who served as project leader; my supervisor, J. M. Holovka; Charles Kirk for drafting, tooling, and fabricating the plastics; C. R. Rethy for designing the diode protection circuits on the bus decode board, the analog switch circuits on the 32Kx8 EEPROM board, and the TEMPEST filter placement on the vestibule; R. Serna for the layout and fabrication of the printed circuit board; and Thomas White who served as the NSA interface on the authenticator project.

[5]

###

### Contents |
___________________________________________________________________ |
Introduction | 7
The DSVS Authenticator | 7
The Algorithm | 13
The F Register | 17
The V Register and State Sequencer | 18
The R Register | 21
The Bus Decode Board | 22
The Command/Status Board | 22
The Watchdog Timer Board | 23
The Mother Board | 24
Maintenance Support Board | 24
The EEPROM Board | 24
Bus Extender Card | 27
External Bus Exerciser | 27
VME Bus-Authenticator Interface Card | 27
IBM PC/XT-to-Authenticator Bus Interface Card | 27
Address Assignments and Functions | 27
Message Formats | 27
Test Source Code | 27
Photographs | 30
Field Test Record | 33
Silicon-Compiled Chip | 35
APPENDIX A--Authenticator Address Map | 39
APPENDIX B--TEMPEST Enclosure Diagrams | 41
APPENDIX C--F Register Schematic | 49
APPENDIX D--V Register and State Sequencer Schematic | 55
APPENDIX E--R Register Schematic | 57
APPENDIX F--F Register Schematic | 61
APPENDIX G--Command/Status Board Schematic | 65
APPENDIX H--Watchdog Timer Board Schematic | 69
APPENDIX I --Mother Board Schematic | 73
APPENDIX J--Maintenance Support Board Schematic | 77
APPENDIX K--32Kx8 EEPROM Board Schematic | 81
APPENDIX L--64Kx8 EEPROM Board Schematic | 85
APPENDIX M--Bus Expansion Board Schematic | 89
APPENDIX N--External Bus Exerciser Schematic | 93
APPENDIX O--VME Bus Interface Schematic | 97
APPENDIX P--IBM PC/XT (ISA) Bus Interface Schematic | 105
APPENDIX Q--NSS Authenticator Addresses | 109
APPENDIX R--Message Formats and Protocol | 123
APPENDIX S--Test Source Code | 145
APPENDIX T--Benincasa's Algorithm Deficiencies | 181
#### Figures |
___________________________________________________________________ |
1 Artists's conception of the authenticator TEMPEST enclosure | 9
2 Artist's conception of the printed circuit card assembly extending from the TEMPEST enclosure | 10

[6]

#### Figures (continued) |
___________________________________________________________________ |
3 Polycarbonate-glass endplate used with authenticator | 11
4 Polycarbonate-glass load/thrust bearing pieces | 12
5 Photograph of the injection mold die for the load/thrust bearing pieces and endplate of the authenticator supports | 13
6 Diagram of the data authenticator algorithm structure | 14
7 Four authenticators to VME U6 bus card | 28
8 Authenticator to PC/XT bus interface card | 29
9 Data authenticator TEMPEST enclosure | 30
10 Disassembled authenticator | 30
11 Authenticator with bus extender and maintenance support board ready to undergo test | 31
12 Authenticator-to-authenticator bus card and cable | 32
13 Memo dated September 3, 1991 | 33
14 Memo dated September 11, 1991 | 34
15 Architecture of authenticator | 35
16 Silicon compiled chip of the algorithm portion of the authenticator | 36
17 Floor plan of the silicon compiled authenticator | 37

[7]

## Data Authenticator for the Deployable
Seismic Verification System

### Introduction

Data authentication is the process of computing a key-dependent checksum of a message. The checksum is appended to the message by the transmitter and checked by the receiver. Messages that contain valid checksums are called authentic messages. Messages with bad authentication checksums either contain errors in the checksum, errors in the message, or are counterfeit.

A data authentication algorithm produces a pseudorandom checksum for each processed message bit. A key is the "seed" for the pseudorandom sequence.

The National Security Agency (NSA) provides data authentication algorithms for treaty verification applications. Most of the algorithms are classified. NSA will declassify a treaty verification algorithm to a classification level that allows it to be shared with a treaty participant after the treaty has been signed.

In 1973 NSA supplied to Sandia National Laboratories (SNL) a data authentication algorithm, called the Unmanned Seismic Observatory algorithm, for use in the Comprehensive Test Ban Treaty seismic verification systems. The report, submitted by R. Benincasa of NSA, is classified and therefore cannot be cited here.

The purpose of this SAND report is to document the construction at SNL of the data authenticator used for the Deployable Seismic Verification System (DSVS). This documentation should be of value in the years to come for those who may want to know how it was built, how to maintain it, and how to upgrade it.

Thus far, SNL has implemented the algorithm three times. Each time, the hardware and software were upgraded. The first implementation was done in 1974, by R. E. D. Stewart, D. A. Reynolds, and J. G. Deasey. This was a "bench test" implementation in the sense that the algorithm was done in hardware wire, wrapped on "cash" cards, and placed in a test rack. This algorithm implementation was done entirely in the hardware. The authenticator hardware was exercised by a Nova 800 minicomputer (Data General Corp.). They did not try to make the authenticator small, low power, or to enclose it in a TEMPEST container. This implementation was for a feasibility study. R. Stewart provided complete documentation, including schematics and computer codes; this also cannot be cited here because it is classified.

The second implementation, by M. A. Schaefer, took place between January 1978 and September 1979. This was done in low-power 4000-series CMOS logic; an NSC800 microcomputer was used to pass bytes to the authenticator hardware and read back the values. This authenticator, which processed data at 19,200 bits per second, was housed in a TEMPEST container that had been tested and approved by NSA. There were, however, three major problems with this second authenticator:

> 1. Its hardware was classified.

> 2. Its cost was high--about $75,000. This included two authenticators and the TEMPEST containers for both. Cost of each container was about $20,000 of this $75,000.

> 3. Its processing speed was low.

### The DSVS Authenticator

The author was assigned to build a third version for the Deployable Seismic Verification System. The goal was to eliminate the problems attributed to the second version. Additional requirements were

[8]

that it be of sufficiently low technology to make it exportable, and that its development costs be kept low. Design and construction began in 1987. This third version of the authenticator was working successfully by 1989.

Since this authenticator was to be attached to the DSVS downhole logic (DHL) and to the Receiving and Monitoring Station (RAMS), interface specifications had to be drawn up and made available at the outset to the hardware designers. The designers were told that the hardware interface would look like an Intel 82C55A Programmable Peripheral Interface chip. If they met the electrical specifications for connecting their systems (the local memory or I/O bus) to an 82C55, they would then be able to communicate with the authenticator. The 82C55A contains a reset, chip select, read, write, three address input lines, and eight bidirectional data lines.

The new authenticator was designed top-down. The next step was to do a preliminary assignment of the chip port functions. The three address input lines offer eight read/write options. The basic function of an authenticator--any authenticator--is to receive data, and to provide status and authenticator values. Key management was also included. The reasons for this were: (1) the keys could be contained in the TEMPEST enclosure; and (2) DHL and RAMS software would be much simpler since the complicated key management software would be included in the authenticator and therefore not duplicated. There was concern that if the interface to the authenticator--in both hardware and software--was not simple, it might be unusable. This required that messages relating to key management be passed into and out of the authenticator, and led to the following chip interface specifications:

Address Offset | Read | Write
0 | Status | Byte-to-authenticate
1 | Low-byte authenticate value |
2 | High-byte authenticate value |
3 | Data-in | Data-out
4 |  |
5 |  |
6 |  |
7 |  |

Blank entries mean that a read or write function has not been assigned. A detailed address map is shown in Appendix A.

The author simulated Benincasa's algorithm on a PC to make sure he could understand it. This was done by comparing the simulated intermediate output provided by Benincasa to the results of the simulation. Benincasa's software was written in APL, the author's in FORTH.

Several meetings with NSA resulted in the directive that the algorithm be implemented in hardware, as opposed to software or a combination of both. The author then proceeded to decompose the algorithm functions, each of which could be contained on a reasonably sized printed circuit board.

The size of the TEMPEST container--and thus the authenticator boards--was constrained by the 5-3/8-in. diameter of the tube into which it had to fit. Room was needed for a cable run under the authenticator; thus, the end profile of the authenticator had to be D-shaped (the length could vary at this stage but the diameter could not).

The next decision was how to include the maximum number of logic chips in a minimum volume. The best method was the packaging used by IBM in the design of its personal computer. Main computer functions are included on a "mother" board. Edge connectors connect "daughter" boards to the mother board. This modular design of a parallel bus system allows us to use the inexpensive 31/2 edge connector.

A mother board was designed using the 80C31 microcontroller, which had local RAM, EEPROM, and I/O space, and fits in the bottom of the D-space. The 80C31 was selected because it was the smallest low-technology processor available that could perform the functions required by the authenticator. One critical function is a high-speed synchronous serial communications link, required

[9]

to load keys into the shift register. Another consideration was that SNL build a radiation-hardened version of the 80C31.

The next step was to select the container. High reliability was required, coupled with low cost in a low-vibration environment. Experts with access to connector reliability data were consulted. As a result, a semi-bellows 31/2 edge connector was selected. This connector is sometimes used in the IBM PC/XT, although more frequently a cantilever beam version is used; the two are interchangeable. The semi-bellows connector has greater mating force.

The TEMPEST container was designed next. Understandably, there were overlaps in time in performing these tasks, but this narrative presents them in an approximate order. A primary objective in designing the container, in addition to satisfactorily performing its intended function, was keeping its cost low. The TEMPEST container used on the previous unit had been machined from a block of aluminum, which had proved to be one of the authenticator's more expensive elements.

Construction methods that were considered included TIG-welded tubing, extrusions, die casting, and rubber-plaster casting. Rubber-plaster casting was selected because of the low cost of the tooling and parts, and the easy evolution to die casting in the event we later required higher volumes. The tool cost was approximately $5000, with an eventual three-piece part cost of approximately $330 for quantities of ten or more. This included the secondary machining and epoxy vacuum filling of the porous aluminum casting.

A conductive glue (Tracon) was used to epoxy together the three-piece TEMPEST container. Glue has very low tensile strength, but high shear strength. The design of the shear surface was such that the electronics could be removed only by machining off the container once it had been joined and cured.

Figure 1 shows a TEMPEST enclosure. The parallel interface connector is located in the recessed face of the container to protect it against mechanical stress. Two authenticators are stacked end to end. The second section of the container is the "vestibule." It contains the TEMPEST rf filters and a dill valve, which is similar to an air valve on an automobile tire. The valve is used to evacuate the interior of the container, then backfill it to a slightly positive pressure with helium. The container is then epoxied shut. Appendix B shows mechanical drawings of the TEMPEST container.

[Image 46K] Figure 1. Artist's conception of the authenticator TEMPEST enclosure.

[10]

Figure 2 shows authenticator PC boards protruding from the TEMPEST enclosure. The top interconnect board was needed because there were not enough interconnect paths on the mother board. A connector with more slots would have made the unit longer, and this would have prohibited the use of the cost-saving PC/XT connector.

[Image 60K] Figure 2. Artist's conception of the printed circuit card assembly extending from the TEMPEST enclosure.

There are seven connectors on the mother board and three on the top interconnect board. Observe also that chips are shown at the bottom of the interconnect board. None appear on the final authenticator. This space was reserved for any additional chips that might be needed. The board spacing, which was to have been the same as on the Regional Seismic Test Network (RSTN), is 1/2 in. on center.

The next step was to design the circuit cards essential to execute the algorithm. The goal was to separate the algorithm by function and have each board near filled to capacity. Details of the design are presented later in this report.

Manila envelopes were cut to the same size as the PC cards. The computer chips were laid over them to ensure they would fit. The mother board was designed first. Foam versions of the boards were cut and the chips were fastened to them. When the PC board layout of the mother board was completed, an additional inch was required for interconnect wiring (6 to 7 in.), even though all of the chips fitted on the foam mother board.

The authenticator PC board assembly is suspended in the TEMPEST container. Because the container is conductive, care must be taken not to short out the electronics. The least expensive technology for the supports proved to be glass-reinforced polycarbonate plastic. The author designed the load/thrust bearing parts, and Charles Kirk (Precision Molded Concepts) refined the drawings for production (Figures 3 and 4), built the mold (Figure 5), and shot the parts. Endplate pins hold the cards vertically. A molded pin at the top of each slot on the endplate was mated into a recess at the end of each PC card. This prevented the cards from leaving the connectors.

[11]

[Image 82K] Figure 3. Polycarbonate-glass endplate used with authenticator. Note the molded pins that secure the edge connector cards in their connectors.

[12]

[Image 49K] Figure 4. Polycarbonate-glass load/thrust bearing pieces. The TEMPEST container includes a 1/2-degree draft for part release. The case process held tolerance to + 0.005 in. The tabs at the top of this part were filed to match the dimensions of individual TEMPEST containers.

[13]

[Image 76K] Figure 5. Photograph of the injection mold die for the load/thrust bearing pieces and endplate of the authenticator supports. The endplate electrode was first machined, and the female impression was EDM'ed from the mold billet. The load/thrust part was machined directly in the billet.

To ensure that all parts of the authenticator package were finished at about the same time, design and construction of the TEMPEST container and the plastic supports was started before the construction of the PC boards. There was risk, of course, that the authenticator would not fit into its container. But there were two hedges to this risk: (1) additional space had been reserved for electrical components on the underside (and possibly even the top side) of the top interconnect board; and (2) programmable array logic chips could be used to reduce the chip count, if necessary, to reclaim space.

### The Algorithm

A general unclassified diagram of the seismic algorithm is presented in Figure 6. One design goal was to keep the hardware unclassified because the authenticator is deployed at unmanned test sites. This is accQmplished by building a hardware device capable of executing numerous authentication algorithms, including classified codes. The computer hardware itself is not classified. The system becomes classified only when it is operating, or contains remnants of, classified information.

[14]

[Image 44K] Figure 6. Diagram of the data authenticator algorithm structure. The algorithm is bit-oriented. Each data bit is exclusively OR-ed with the low-order bit of a 16-bit V register. This output is exclusively OR-ed with the low-order bit of a 63-bit linear feedback shift register. This is called the F register. This output is exclusively OR-ed with a boolean function, 14-bit R register. The high-order 10 bits of the R register are the authentication checksums. The V and F registers contain the 79-bit key.

The NSA R register feedback function is classified. For each data bit processed, both the F and R registers are stepped multiple times. The number of steps is classified. All remaining parts of the algorithm are unclassified. The output from the R shift registers is used as address lines into a fast static CMOS 16Kx1 RAM. The output of the RAM is fed back into the R register. The boolean feedback function is loaded into the static RAM under the control of an 80C31 microcontroller; the step value is loaded into a latch under the software control of an 80C31 microcontroller. The classified aspects of NSA's algorithm reside in software.

The data authenticator is its own development system. It hosts an operating system, compiler, assembler, and full-screen editor. The only development tools required are a personal computer, a logic probe, and (infrequently) an oscilloscope. The authenticator software is designed to be given in its entirety to any treaty participant; thus, all software used is in the public domain. SNL's operating system is FORTH.

A personal computer is connected, via a serial port, to a daughter board called a Maintenance Support Board. This board contains either a 32Kx8 EPROM or EEPROM. This board also contains a National 82C50 Asynchronous Communications Element, and contains the authenticator's operating system during hardware check-out and software development time. The board communicates both terminal and disk data over a serial port running at 19.2 kilobits.

A terminal/disk program that runs on a personal computer makes it possible for the user to log on to an authenticator. When this program is running, the authenticator takes keyboard input from the PC and outputs data to the PC screen. The authenticator can also read or write from a single-disk file located on the PC. The easiest way to show how an authenticator works is by example; therefore, the author will log on to the authenticator and give some examples. Borland's SideKick is used to capture

[15]

screen output from the authenticator into a note file. This note file is read into this report. After the terminal emulator program is entered and the authenticator is powered, the logo will appear on the screen.

8051 televideo 910 terminal emulator
Authenticator 8051 series microcontroller ROMed DOS MC 2.2 19.2 kbs, rts, cts flow control Version 1.412/33/89 09:42
ok

The first line on the screen is printed by the terminal emulation program. The lines beginning with "Authenticator" are from the authenticator.

The following shows an example for making interactive calculation 2 plus 3 and printing the result; compiling and running an interactively entered program that prints out the indices of a loop counter; and assembling and testing an interactive assembler routine.

> >     2 3 + .  5 ok
> >     : X 5 0 DO I CR . LOOP ; X
> >     0
> >     1
> >     2
> >     3
> >     4 ok
> >     CODE Y GETSP, A # 9 MOV  A0PUSH, END-CODE Y . 9 ok

A book by William H. Payne (the author of this report), Embedded Controller FORTH For the 8051 Family (Academic Press, Inc.; Harcourt, Brace, and Jovanovich, 1990) contains all the details of the operating system.

Authenticator applications software was entered interactively from disk files and debugged. The software was then combined with the operating system. The operating system plus the application code was metacompiled and ROMed. The examples using the authenticator boards are invoked from ROMed code.

Examples of each of the authenticator's daughter boards will be demonstrated from the keyboard to show how the hardware operates. The authenticator I/O bus closely resembles the PC/XT. Because the authenticator uses the 80C31 instead of the 8086/88, pin definitions are not exactly the same. Pins not used by the 80C31 are used for authenticator-specific functions. Here is the internal bus definition:

[16]

>                                                     5/09/89 whp

>                         AUTHENTICATOR INTERNAL BUS

>      i/o pin    signal name    i/o       i/o pin   signal name    i/o

>      Al        -RD&-PSEN        o       *Bl        F out          i/o
>      A2         D7             i/o       B2        RESET          i/o
>      A3         D6             i/o      *B3        V out          i/o
>      A4         D5             i/o      +B4       -INTO P3.2      i/o
>      A5         D4             i/o      +B5        P1.1 Poll req  i/o
>      A6         D3             i/o      *B6        Clk FR          i/o
>      A7         D2             i/o      ^B7
>      A8         D1             i/o      +B8        P1.4           i/o
>      A9         D0             i/o      ^B9
>      A10       -PSEN            o       +B10       P1.6           i/o
>      All       -FF              o       +Bll      -WR P3.6        i/o
>     +A12        P1.0 clr int0  i/o      +B12      -RD P3.7        i/o
>     +A13        P1.2 Soft busy i/o      +B13       P3.0 RxD       i/o
>     +A14        P1.3           i/o      +B14       P3.1 TxD       i/o
>     +A15        P1.5           i/o      *B15       Clk DV         i/o
>      A16        A15             o       *B16       Step           i/o
>      A17        A14             o       *B17       D+V            i/o
>      A18        A13             o       *B18       Osc Busy       i/o
>      A19        A12             o       +B19       P1.7 IntO in   i/o
>      A20        A11             o       +B20       P3.4 TO        i/o
>      A21        A10             o       *B21       GO             i/o
>      A22        A9              o       *B22       R int          i/o
>      A23        A8              o       *B23       F int          i/o
>      A24        A7              o       *B24       V int          i/o
>      A25        A6              o       +B25      -INT1 P3.3      i/o
>      A26        A5              o       +B26      -RAM Osc offline
>      A27        A4              o       +B27      -ROM maintenance support
>      A28        A3              o        B28       ALE             o
>      A29        A2              o        B29      +5 Vdc          power
>      A30        A1              o       +B30       P3.5 T1        i/o
>      A31        A0              o        B31       GND            ground

>     * no termination on motherboard
>     + jumpered on motherboard
>     ^ not used on battery powered motherboard

[17]

The external bus is the top interconnect board connection. Its pin definition is:

>                                                      02/08/89 whp

>                        AUTHENTICATOR EXTERNAL BUS

>     i/o pin    signal name    i/o       i/o pin   signal name    i/o

>     XA1        XD7            i/o       XBl       D reg/status   i/o
>     XA2        XD6            i/o       XB2
>     XA3        XD5            i/o       XB3       R1
>     XA4        XD4            i/o       XB4       RO
>     XA5        XD3            i/o       XB5
>     XA6        XD2            i/o       XB6       Data in/out
>     XA7        XDl            i/o       XB7
>     XA8        XDO            i/o       XB8
>     XA9        XAO            i         XB9
>     XAlO       xAl            i         XB10
>     XAll       XA2            i         XBll
>     XA12      -XCS            i         XB12
>     XA13      -xRD            i         XB13
>     XA14      -XWR            i         XB14
>     XA15       XRESET         i         XB15
>     XA16       Outl           o         XB16
>     XA17       Out2           o         XB17
>     XA18                                XB18
>     XA19                                XB19
>     XA20                                XB20
>     XA21                                XB21
>     XA22                                XB22
>     XA23                                XB23
>     XA24                                XB24
>     XA25                                XB25
>     XA26                                XB26
>     XA27                                XB27
>     XA28                                XB28
>     XA29                                XB29
>     XA30                                XB30
>     XA31                                XB31

### The F Register

The F register is a 63-bit linear feedback shift register built with parallel-out, high-speed CMOS chips. It is contained on a single card. The shift register clock and data-in inputs are multiplexed so that the shift register can be clocked from software. The FORTH command FEXT selects the software clock. FINT selects the hardware clock. ONE places a logic 1 at the input to the register; ZERO places a logic 0 at the input. CLOCK is defined: CLOCK--CLK CLK ;. CLOCK drops the clock input to the register low, then high. This causes the input to be shifted one position to the right. The command CLRF clears the F register. Following is a dialog with an authenticator placed just left of the keyboard while the author is writing this report. .F prints a copy of the F register.

[18]

>     F Register
>     x is the unused 64th bit of the linear feedback shift register
>     6 5          4         3         2         1         0
>     210987654321098765432109876543210987654321098765432109876S43210x
>     0100000000000000000000000000000000000000000000000000000000000000ok
>     CLRF ok
>     6 5         4         3         2         1         O
>     210987654321098765432109876543210987654321098765432109876543210x
>     OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOok
>     FEXT ok
>     ONE CLOCK ok
>     F Register
>     x is the unused 64th bit of the linear feedback shift register
>     6 5          4         3         2         1         0
>     210987654321098765432109876543210987654321098765432109876543210x
>     1000000000000000000000000000000000000000000000000000000000000000ok
>     CLOCK .F
>     F Register
>     x is the unused 64th bit of the linear feedback shift register
>     6 5          4         3         2         1         0
>     210987654321098765432109876543210987654321098765432109876543210x
>     1100000000000000000000000000000000000000000000000000000000000000ok
>     ZERO CLOCK .F
>     F Register
>     x is the unused 64th bit of the linear feedback shift register
>     6 5          4         3         2         1         0
>     210987654321098765432109876543210987654321098765432109876543210x
>     0110000000000000000000000000000000000000000000000000000000000000ok
>     CLOCK .F
>     F Register
>     x is the unused 64th bit of the linear feedback shift register
>     6 5          4         3         2         1         0
>     210987654321098765432109876543210987654321098765432109876543210x
>     0011000000000000000000000000000000000000000000000000000000000000ok
>     ONE CLOCK .F
>     F Register
>     x is the unused 64th bit of the linear feedback shift register
>     6 5          4         3         2         1         0
>     2109876543210987654321098765432109876S4321098765432109876543210x
>     1001100000000000000000000000000000000000000000000000000000000000ok

This demonstration shows that some of the F registers appear to work properly. Diagnostics can be interactively written or run in a batch mode to isolate faults quickly.

Appendix C presents the F register schematic.

### The V Register and State Sequencer

The V register is a 16-bit circular shift register. Serial input permits loading using the 80C51 Mode O synchronous serial expansion communications. Parallel read-out on the bus allows the user to verify that the load matches the read-out. The clock is multiplexed between software and a crystal oscillator. Below is a demonstration of the V register operation, taken directly from an authenticator onto the same screen and used to write this report. CLRV clears the contents of the V register. ONE places a 1 at the V register input; ZERO places a 0 at the input. CLOCK drops the multiplexed input to the shift register low, then high. VEXT selects the software clock, and VINT selects the hardware oscillator.

[19]

>     CLRV ONE CLOCK .V
>     V Register
>     1    0
>     5432109876543210
>     1000000000000000ok
>     CLOCK .V
>     V Register
>     1    0
>     5432109876543210
>     1100000000000000ok
>     ZERO CLOCK .V
>     V Register
>     1    0
>     5432109876543210
>     0110000000000000ok
>     ONE CLOCK CLOCK CLOCK ZERO CLOCK CLOCK ONE CLOCK CLOCK .V
>     V Register
>     1    0
>     5432109876543210
>     1100000000000000ok

The hardware state sequencer supplies clocks to the authenticator hardware logic. The clock to the state sequencer is multiplexed so that it can be "single-stepped" from software, run at full software speed, or run from a hardware crystal oscillator. The speed of operation of the state sequencer requires the use of several advanced CMOS logic chips instead of the high-speed CMOS.

The history of the state sequencer is informative. Its design, prototype, and the initial tests were all subcontracted. The subcontractor implemented the circuit using only a crystal input; the design was implemented on an authenticator daughter board. The oscillator was routed to a port pin on the mother board 8051. The subcontractor's design contained a logic fault, however, that could not be easily fixed. The author had to redesign the circuit and order high-speed CMOS parts. L. vanBlaricum (SNL) found that the oscillator frequency could be halved by changing only one wire. This improvement was incorporated into the design.

The state sequencer is complicated from the standpoint of (1) making it produce the right clocks transitioning on the correct edges, and (2) stopping. The sequencer is designed to produce full clocks (no partial clocks) without skew. The faster it runs, the more difficult it is to produce the final clock, and then stop. HC74's run at only half their rated speed. Before vanBlaricum's improvement, clock pulses were rounded off at frequencies above 10 MHz.

Appendix D is a schematic of the V register and state sequencer. The number of steps for each bit is stored in the software's loaded latch (U20, an HC374). This number can range from 0 to 255.

Following is an example for loading '5' into the step latch, and printing the contents of the latch. '7' is then loaded into the latch and the contents are verified by reading and printing, which is done by the command .STEP.

5 STEP C! .STEP 5 ok 7 STEP C! .STEP 7 ok

The contents of the state sequencer can be read on the 80C51 bus. The command .OSC does this. S stands for Step, 8 for divide by 8, 3 for divide by 32, and B is the "busy" bit that indicates that the oscillator is busy. Following is an example of the state sequencer in its initialized state:

S83B 1110ok

[20]

The state sequencer can be exercised from software in either a static mode or at full software speed. Below is a program that the author entered from the screen employing vanBlaricum's modified state sequencer:

>     : T INITOSC OSC -OSC .OSC SGO CR (.OSC)
>     BEGIN -CLK CR (.OSC) CLK CR (.OSC) PCEY 27 = IF QUIT THEN AGAIN ;
>     ok

INITOSCR initializes the state sequencer by setting the step to 32. OSC connects the hardware oscillator to the state sequencer, which causes it to return to an initialized condition.--OSC connects the software clock to the state sequencer. .OSC prints the state of the state sequencer. (.OSC) prints the oscillator state without CRs. SGO gives a start pulse to the state sequencer. Writing a byte to be authenticated does the same function when the hardware oscillator is connected. --CLK drives the clock low; CLK drives it high. CR is a carriage return. The program continues until the escape key (hex lB, decimal 27) is keyed.

Following is the first part of the sequence when the program is invoked:

>     T
>     S83B
>     1110
>     1111
>     1111
>     1111
>     1101
>     0011
>     0001
>     0111
>     0101
>     0111
>     0101
>     0111
>     0101

The output below from the state sequencer shows it clocking the data and setting the step gate:

>     0101
>     0111
>     0101
>     llll
>     1101
>     0011
>     0001
>     0111

The vanBlaricum clock differs from the original in that all clock inputs are held high and the clock to be pulsed is given a single high-low-high pulse. Note that the--CLK - CLK sequences are used as commands to exercise the modification. The original clock is used on CLOCK commands (: CLOCK --CLK CLK ;). The original clock, however, operates at twice the frequency. Four authenticators (deployed) have been authenticating about 1900 bytes per second for 1-1/2 years with no observed

[21]

failures (there are other authenticators in the field; memorandums addressing the field record are presented later in this report). No problems with the state sequencer have been observed.

### The R Register

The R register is a 14-bit boolean feedback shift register. NSA's feedback function for the R register is classified. This R register takes the output of two serial-in, parallel-out shift registers as address inputs into fast (20 ns) 16Kx1 static RAM. The boolean function output is the data bit out. The static RAM is filled by loading the R register's serial input with the address of the bit to be accessed. One can write to the RAM by decoding a location in I/O space.

There are 2**14 possible R register feedback functions.

The R register occupies an entire daughter board. Appendix E shows the schematic of the R register.

The contents of the R register are loaded with the command TOR (to R) and printed with the command .RREG. The state sequencer oscillator must be disconnected before setting the R register. Following are several examples for setting the R register:

>     1 TOR ok
>     .RREG
>     R Register
>     1     0
>     54321098765432xQ
>     0000000000000101ok
>     2 TOR
>     .RREG
>     R Register
>     1     0
>     54321098765432xQ
>     0000000000001001ok
>     4 TOR
>     .RREG
>     R Register
>     1     0
>     54321098765432xQ
>     0000000000010001ok

Note that the bits are shifted two places to the right. This is because only the high-order 14 bits are used (see U13 on the schematic). The column labeled 'Q' is the output of the RAM (see pin 17, U14). The column labeled 'x' is always 0 since it is tied to ground (pin 15, U14).

The contents of the static RAM are dumped with the command DRAM, which requires Start Address/Length as arguments. Following is an example for dumping the first 100 locations, starting at location 0.

>     0 100 DRAM
>     0110011111101100111100111011100001001101101100111111111111000000
>     110010011110011101001111000100001111
>     ok

Now, we have an example of storing a '1' to location 0, fetching location 0, and printing it. The first 10 locations are dumped.

>     1 0 !RAM 0 @RAM . 0 10 DRAM
>     1110100101
>     ok

The same operations are repeated, except that a '0' is stored.

[22]

>     1 0 !RAM 0 @RAM . 0 10 DRAM 0
>     1110100101
>     ok

The static RAM is zeroed with the command ZERORAM. Following is an example:

>     ZERORAM
>     ok
>     0 100
>     DRAM
>     000000000000000000000000000000000000000000000000000000000000000000000000
>     000000000000000000
>     ok

The static RAM was tested with the RT command by writing 0's and 1's to it. The RAM was read to see if the results are correct. Following is an example:

>     RT
>     0
>     1
>     2
>     3
>     4
>     5
>     6
>     7
>     8
>     9
>     10
>     11
>     ok

The column number identifies the location in memory. If an error occurs, a message identifies a "bad one" or a "bad zero."

Using a fast-column static RAM to hold the feedback function was sufficiently risky to justify wire-wrapping and testing it before building a board.

### The Bus Decode Board

The functions of the bus decode board are to route the authenticator input and output signals to the authenticator bus; provide overvoltage protection, some power filtering, added pull-up resistors (vanBlaricum), and Schmitt-trigger input buffers (vanBlaricum) so that the authenticator can work reliably at the end of approximately 15 ft of cable at the Receiving and Monitoring Station. The added pull-ups and Schmitt trigger buffers were not included in an earlier version of the board. Appendix F shows the schematic of the bus decode board.

### The Command/Status Board

The command/status board stores the data byte to be authenticated, gives output status, buffers a data message input byte, holds a data message output byte, and contains the interrupt hardware. Appendix G shows the schematic for the command/status board.

The data byte to be authenticated is held in the D register. This is the source of Data Bits in Figure 6. This is an HC165 parallel-in, serial-out shift register (chip U2). A 'write' to the D register (offset 0) triggers the authenticator to perform a 'hardware authenticate'.

[23]

The command .IS prints the contents of the status register internal to the authenticator. The status register can also be read externally through the connector. Following is an example:

Internal bus status 1 D register 0 Watchdog time-out 0 Data out ready 1 Software busy 1 Poll Micro 1 INT1 0 INT0 1 Osc busy ok

The D register.can be taken off-line so that it will not accept a byte through the external connector. The command to disable the D register is DEXT; the command to enable it is DINT.

A '1' in the 'watchdog time-out' means that the authenticator watchdog timer timed out and was not reset by the 80C31.

In 'data-out ready' a '1' means that the authenticator wrote a byte to the outside world and that it has been read through the connector. This bit is cleared when the data is read through the external connector.

'Software busy' and 'Poll Micro' are an 80C31 software set bit to indicate the status of the authenticator software. They are controlled by the FORTH command SB (set),--SB (clear), SPOLL (set), and--SPOLL (clear).

'INT1' set means that a byte has been written to the authenticator from the outside world through the connector. It is cleared when the authenticator 80C31 reads the byte.

'INT0' set means that a frame start is requested from the outside world. When this is set, the 80C51 executes an INT0 interrupt and loads the current key into the R and V registers with a 1-megabitper-second serial (Mode 0) load.

The 'OSC busy' set indicates that the state sequencer has been activated but is not done. 'OSC busy clear' indicates that the authenticator is ready to accept a byte (providing the D register is connected, status bit clear).

### The Watchdog Timer Board

The watchdog board contains the watchdog timer. If the timer is activated and times out, it performs a hardware reset on the 80C31. The board also contains a piezoelectric buzzer, six light-emitting diodes (LEDs), and a battery backed-up real-time clock calendar.

NSA hardware and software guidelines state that the cryptographic device should give clear audio and visual indications that it has passed the self-test. The buzzer and LEDs perform this function.

A record of key manipulation activities requested from the outside world consists of date/time stamped. The authenticator can be interrogated for a history of activity. An example of screen output response to the command SHOWTIME is:

Wednesday 09/04/91 02:20:28 pm

The authenticator used to write this report has been unpowered for about six months. The clock was not trimmed, but the authenticator still responded with the correct date within 10-minute accuracy. The date/time stamping resolves conflicts regarding what commands were sent to the authenticator at what time.

Software or hardware faults can cause a processor to "hang" in an unending loop. The watchdog timer's function is to correct software upsets. The code

1 $: SCON 1 $ JNB

[24]

could lead to an endless loop. The watchdog, however, will time out and reset the processor. This would bring the processor out of the loop. The watchdog timer is implemented with a serial-in, parallel-out shift register. The input is a '1'. The '1' is shifted slowly to the right. The watchdog shift register is cleared by writing to it. If it does not receive a 'clear' by the time a '1' is shifted to the far right position, the watchdog resets the 80C31.

The word FIDO exercises the watchdog timer. In the example, FIDO is typed and the watchdog timer times-out. Two final zeros are printed. The reason for this is that the 1's are shifted at a frequency of 1 ms and reset was entered before the first two 1's were printed. The time-out invokes a hardware reset so that the cold start logo is printed.

Watchdog Timer Demo Hit a key to reset the dog or ESC to stop the dog 11111100 Authenticator 8051 series microcontroller ROMed DOS MC 2.2 19.2 kbs, rts, cts flow control Version 1.4 12/33/89 09:42 ok

The authenticator beeps at different frequencies and durations as it proceeds through the power-on reset. It also turns off its LEDs in order. If this does not occur, it is likely that the authenticator has not successfully completed initialization. The authenticator gives positive acknowledgment of successful initialization.

A schematic of the watchdog timer board is presented in Appendix H.

### The Mother Board

The mother board contains an 80C31, a 32Kx8 EEPROM, 32Kx8 byte RAM, and address-mapped 256 I/O locations. --PSEN and --RD are ANDed together to combine the code and data spaces. EEPROM--RD,--WR, and --CS are jumpered. Software can be transferred from a PC through its serial port to EEPROM soldered on the mother board. When the transfer is complete, EEPROM --WR can be tied high, disabling further "writes" to it.

Details of the mother board are included in the author's book, Embedded Controller FORTH For the 8051 Family (Academic Press; Harcourt, Brace, and Jovanovich, 1990).

Appendix I shows the schematic of the mother board.

### Maintenance Support Board

The maintenance support board contains 32Kx8 bytes of either EEPROM or EPROM. The type of ROM is jumper-selectable. The board also contains a National 82C50 access control element for serial communication to a PC. A Maxim 5-volt-only 235 is used for line drivers and receivers. The schematic for this board is in Appendix J.

### The EEPROM Board

The authentication keys are contained in a 32Kx8 byte EEPROM or 64Kx8 EEPROM board. 'Bulk memory erase' is implemented in both voltages to erase the memory, whereas the 64K needs only + 5.

In the event of a 'tamper detect', the downhole logic unit sends a command to the authenticator that causes it to bulk-erase the keys. The only 'tamper detect' is a microswitch closure that indicates that the authenticator is being lifted from its borehole.

[25]

Following is an example of the operation of the 32K board. INITEE initializes the logic for controlling the power to the chip. A DC-DC converter and analog switches are required to control the power to the chip. Locations 0 to 100 of the EEPROM are dumped.

>     INITEE 0 100 EDUMP

>            0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEF

>        0  02 00 54 02 80 64 00 00 02 00 00 02 80 67 00 00  ..T..d.......g..
>       10  02 00 00 02 80 6A 00 00 02 00 00 02 80 6D 00 00  .....j.......m..
>       20  02 00 00 02 80 70 00 00 02 00 00 02 00 75 01 03  .....p.......u..
>       30  00 OE 44 06 00 08 F6 B6 F5 B6 F6 B6 F5 B7 00 1F  ..D.............
>       40  00 00 80 73 80 73 3E 4D 00 05 B2 B5 F5 B6 F6 B6  ...s.s>M........
>       50  F6 B6 23 5B 75 81 2F 90 00 4C EO FC A3 EO FD 90  ..#[u./..L......
>       60  00 4E En FE A3 EO FF 90 00 52 E5 82 FB E5 83 FA  .N.......R......
>     ok

The memory has an additional 64 bytes for tracking the part's use. This memory is dumped using the EEDUMP verb. This is an example:

>     0 10 EEDUMP

>           0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEF

>     7FC0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
>     7FD0 1B FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
>     7FE0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
>     7FF0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
>     ok

The chip is erased with the ECHIP command. Here, we have an example of the dump, after erasure, of the first hex 100 bytes of the part:

>     ECHIP ok
>     0 100 EDUMP

>            0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEF

>        0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
>       10  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
>       20  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
>       30  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
>       40  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
>       50  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
>       60  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
>     ok

The following is an example of programming the part with a '3' in location 3.

>     3 3 EC! ok
>     0 10 EUDUMP

>            0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEF

>        0  FF FF FF 03 FF FF FF FF FF FF FF FF FF FF FF FF  ................
>     ok

[26]

The 64K FLASH board is bulk-erased with the following code. The code sequences are internally processed by the FLASH memory to complete the erase.

>     HEX
>     CODE ECHIP0    DPTR # EEPROM MOV
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A # 0AA MOV  @DPTR A MOVX
>                    DPTR # EEPROM MOV
>                    A #  2A MOV  @DPTR A MOVX  DPTR INC
>                    A # 0AA MOV  @DPTR A MOVX  DPTR INC
>                    A # 055 MOV  @DPTR A MOVX
>                    DPTR # EEPROM MOV
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A #  80 MOV  @DPTR A MOVX
>                    DPTR # EEPROM MOV
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A # 0AA MOV  @DPTR A MOVX
>                    DPTR # EEPROM MOV
>                    A #  2A MOV  @DPTR A MOVX  DPTR INC
>                    A # 0AA MOV  @DPTR A MOVX  DPTR INC
>                    A # 055 MOV  @DPTR A MOVX
>                    DPTR # EEPROM MOV
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A #  10 MOV  @DPTR A MOVX
>                    NEXT LJMP  END-CODE
>     HEX
>     CODE ECHIP1    DPTR # EEPROM MOV
>                    A #  55 80 OR MOV  @DPTR A MOVX  DPTR INC
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A # 0AA MOV  @DPTR A MOVX
>                    DPTR # EEPROM MOV
>                    A #  2A 80 OR MOV  @DPTR A MOVX  DPTR INC
>                    A # 0AA MOV  @DPTR A MOVX  DPTR INC
>                    A # 055 MOV  @DPTR A MOVX
>                    DPTR # EEPROM MOV
>                    A #  55 80 OR MOV  @DPTR A MOVX  DPTR INC
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A #  80 MOV  @DPTR A MOVX
>                    DPTR # EEPROM MOV
>                    A #  55 80 OR MOV  @DPTR A MOVX  DPTR INC
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A # 0AA MOV  @DPTR A MOVX
>                    DPTR # EEPROM MOV
>                    A #  2A 80 OR MOV  @DPTR A MOVX  DPTR INC
>                    A # 0AA MOV  @DPTR A MOVX  DPTR INC
>                    A # 055 MOV  @DPTR A MOVX
>                    DPTR # EEPROM MOV
>                    A #  55 80 OR MOV  @DPTR A MOVX  DPTR INC
>                    A #  55 MOV  @DPTR A MOVX  DPTR INC
>                    A #  10 MOV  @DPTR A MOVX
>                    NEXT LJMP  END-CODE
>     : ECHIP        ECGIP0 ECHIP1 ;

[27]

The schematic for the 32Kx8 board is presented in Appendix K; the schematic for the 64Kx8 board is in Appendix L.

### Bus Extender Card

The authenticator contains seven edge connectors on the mother board. All are used during the operation of the mother board. In order to have room to plug in the maintenance support card, a bus extender card containing three additional edge connects was built. The expansion card has two edge connections on either end. This permits it to be inserted into either end of the mother board--the A side or the B side. The schematic for this board is presented in Appendix M.

### External Bus Exerciser

The external bus exerciser is a board that simulates the proper external interface to send commands to an authenticator. It plugs into the mother board of an authenticator. One authenticator acts as the external interface to another authenticator. In this way, the authenticator interface can be checked for proper operation. The schematic of this board is presented in Appendix N.

### VME Bus-Authenticator Interface Card

The "de-authentication" or authentication verification requires that the receiver process an incoming data frame and compare its computed authentication value with that in the received frame. Receiver station computers will generally be in machines having the larger bus architecture. Therefore, the author helped design four authenticators to a VME bus card. Bill Holloway and Don Baril (VME, Inc.) designed the interface. A bare card is seen in Figure 7. The cara, on the VME side, has been debugged and is waiting for the authenticator side to be debugged. The board, which meets IEEE 1014 specifications, is jumpered to meet previous revised (IACKIN not before IACK at interrupter) standards. The board fits in a 6U slot. The schematic is shown in Appendix O.

### IBM PC/XT-to-Authenticator (ISA) Bus Interface Card

An IBM PC/XT-to-authenticator interface card was designed for the purpose of (1) deauthenticating PC hosts; (2) keying authenticators; and (3) testing authentications with inexpensive PCs. Additional buffering and pull-up resistors were added to help drive through authenticator TEMPEST filters. De-authentication does not usually require that an authenticator be housed in its TEMPEST enclosure. A photograph of the board is seen in Figure 8. Wait state logic was included. The current authenticator requires no additional wait states, but a future single-chip authenticator may; therefore, wait state logic was included for future use. The board schematic is shown in Appendix P.

### Address Assignments and Functions

Authenticator addresses are assigned as the cards are tested. Appendix Q gives the address assignments. Address selection is determined by jumpers.

### Message Formats

Messages may be sent to or received from the authenticator by reading or writing data bytes. Appendix R gives the formats of the message read or written to the authenticator. Each message written to the authenticator must include a CRD-16 checksum.

### Test Source Code

The test source code includes the FORTH operating system. If a failure occurs, a maintenance support board can be plugged into the device and the operating system used to find the problem. This code is in a form that can be processed by Sandia's Nautilus 2 metacompiler.

Final code involves removing all of the code not referenced by the application and including hardware diagnostics (not part of this report). Some classified code can be added. This source is metacompiled to produce a minimum-sized binary image. The test source code is shown in Appendix S.

[28]

[Image 261K] Figure 7. Four authenticators to VME U6 bus card.

[29]

[Image 221K] Figure 8. Authenticator-to-PC/XT bus interface card. Additional buffering and pull-up resistors are added to drive through the authenticator TEMPEST filters.

[30]

### Photographs

Figure 9 shows an authenticator in its TEMPEST enclosure. A disassembled authenticator is shown in Figure 10. The TEMPEST enclosure is made up of three parts: the cap, the vestibule, and the body. The vestibule contains TEMPEST rf filters and Dill values for evacuating and backfilling the body with helium. The aluminum enclosure was epoxy-treated in a vacuum to eliminate porosity and hold the helium. The approximate cost of the TEMPEST enclosure, including secondary machining and epoxy fill, is $330 in quantities of ten. The length of the unit is 10-1/2 in.; its diameter is 5-3/8 in.

[Image 45K] Figure 9. Data authenticator TEMPEST enclosure. The three pieces of the enclosure are glued together with conductive epoxy. Shear and tensile glue strength requires that the enclosure be machined apart to remove the authenticator's electronics.

[Image 34K] Figure 10. Disassembled authenticator.

[31]

Figure 11 shows an authenticator ready to undergo testing. The maintenance support board is inserted in a bus extender. Figure 12 shows an authenticator-to-authenticator interface card and cable. This card is used to simulate a proper downhole logic hardware interface and checks out authenticators through the connector.

[Image 178K] Figure 11. Authenticator with bus extender and maintenance support board ready to undergo test.

[32]

[Image 145K] Figure 12. Authenticator-to-authenticator bus card and cable. This card was used to simulate a proper downhole logic interface to an authenticator. Note that the TEMPEST filters were bypassed.

[33]

### Field Test Record

Two SNL memos (Figures 13 and 14) document the field record of authenticators deployed to date.

> Sandia National Laboratories Albuquerque, New Mexico 87185
>        date: September 3, 1991

>          to: J. W, Walkup, 9233

>              [Signature]

>        from: W. H. Payne, 9244

>     subject: DSVS data authenticator deployment record.

>       You have been involved in the deployment of data authenticators.

>       Could you please tell me in a memorandum for the record.

>            1. How many are in operation?
>            2. Where are they located?
>            3. How many bytes for each authenticator over what time
>               have been authenticated?
>            4. What is the reliability record?

>       The answers do not have to be exact. Thank you for your help.

>       whp : whp
Figure 13. Memo dated September 3,1991.

[34]

> Sandia National Laboratories Albuquerque, New Mexico 87185
>        date: September 11, 1991

>          to: Bill Payne, 9236

>              [Signature]

>        from: James Walkup, 9233

>     subject: DSVS authenticator records

>                  In reply to your memo of Sept. 3 requesting data on deployed
>              DSVS authenticators, I have the following information.

>                  1. There are currently four authenticators in field operation
>                  (#14, #16, #5, #7). At other times there have been four
>                  others (#12, #17, #8, #15).

>                  2. The four currently deployed are at the Pinedale Seismic
>                  Research Facility (AFTAC) near Boulder, Wyoming.

>                  3. The following table shows the authenticators deployed, the
>                  number of bytes that each has authenticated, and the dates
>                  that they were in Wyoming.
>                  Auth. #     # of bytes each     Dates of deployment
>                  12 & 17     3.1 x 109           4/22/90 to 5/11/90
>                  8 & 15      20.5 x 109          7/9/90 to 11/13/90
>                  14 & 16     58.2 x 109          5/ll/90 to 7/9/90
>                                                  ll/13/90 to 9/11/91
>                  5 & 7       2.2 x l09           11/13/90 to 9/11/91

>                  4. There have been no hardware failures of any
>                  authenticators. However, there was one anomaly that cannot be
>                  explained. On 6/6/91 we were not receiving authentication
>                  bytes from authenticators 5 & 7. On 7/17/91 we began
>                  receiving them again. The problem could have been in either
>                  the DHL or the authenticators

>                  Note: There are five authenticators at the RAMS facility in
>                  Albuquerque, and one authenticator at Patrick AFB in Florida.
>                  I don't know when these units were installed, but I would
>                  estimate that one of the units in Albuquerque has done about
>                  100 x 109 bytes and the one in Patrick has done about 60 x
>                  109 bytes.
Figure 14. Memo dated September 11, 1991.

[35]

### Silicon-Compiled Chip

The layout of the authenticator algorithm's processing hardware is similar to that of a computer chip--specifically, an Intel 82C55A programmable peripheral interface chip but it is implemented with the discrete CMOS logic chips. Two university professors took the authenticator algorithm design and silicon-compiled the design using the GENESIL compiler. This design included the F, V, R, D, and state sequencer (osc) seen in Figure 15.

[Image 63K] Figure 15. Architecture of authenticator. The silicon compiled chip of the algorithm extracted the F, V, R, D, and state sequencer (osc) portions of the authenticator for placement on a single chip.

The chip is shown in Figure 16; the associated floor plan is shown in Figure 17. This work began about the same time as the construction of the authenticator described in this report. Sandia Labs needs a small, low-power, high-peformance authenticator for such applications as video authentication. The present authenticator is specifically designed for seismic applications: it authenticates about 20,000 bytes per second and can be modified to run faster. It draws 200 mA when operating at full speed. This includes the 80C31 microcontroller mother board, EEPROM, and the watchdog, clock. and calendar boards.

Simulations using the silicon compiler show the estimated power consumption to be 250 mA. Lack of capability to eliminate unneeded transistors using the silicon compiler caused the power consumption to be unacceptably high.

The author found several deficiencies in NSA's algorithm. These were reported to the Agency in a June 21,1989, draft memorandum (Appendix T). NSA designed a new data authentication algorithm that eliminated many of the problems associated with the old algorithm.

[36]

[Image 137K] Figure 16. Silicon compiled chip of the algorithm portion of the authenticator.

[37]

[Image 133K] Figure 17. Floor plan of the silicon compiled authenticator.

[38]

Work on the silicon-compiled chip has been halted. Another chip construction technology that applies to the new algorithm appears to be the best strategy for building a high-speed, low-power authenticator chip.

[39]

### APPENDIX A

### Authenticator Address Map

[40]

Authenticator Address Map Address Offset
A2 | A1 | A0 | Read | Write
0 | 0 | 0 | Status | D Register
0 | 0 | 1 |  |
0 | 1 | 0 | R reg high byte |
0 | 1 | 1 | R reg low byte |
1 | 0 | 0 |  |
1 | 0 | 1 | Data out | Data in
1 | 1 | 0 |  | Frame Start
1 | 1 | 1 |  |
Frame Start is initiated by writing any byte value to offset 6. This invokes a --INTO interrupt in the 80C31; the software reloads the V and F current keys and zeroes the R register.

[41-42 not provided]

### APPENDIX B

### TEMPEST Enclosure Diagrams

[43]

[Image 125K] Technical drawing: Container vestibule - Item 2 - Authenticator TEMPEST

[Duplicate of 43; 44 not provided]

[45]

[Image 59K] Technical drawing: Container vestibule - Item 3 - Cap

[46]

[Image 91K] Technical drawing: Cap - Authenticator TEMPEST - Item 3

[47]

[Image 108K] Technical drawing: Authenticator TEMPEST Container

[48]

[Image 94K] Technical drawing: Enclsoure - Item 1 - Authenticator TEMPEST

[49; 50 blank]

### APPENDIX C

### F Register Schematic

[51-52]

[Image 171K] Technical drawing: F Register Decoder Board

[53; 54 blank]

### APPENDIX D

### V Register and State Sequencer Schematic

[55-56]

[Image 173K] Technical drawing: V-Register and OSC Decode

[57; 58 blank]

### APPENDIX E

### R Register Schematic

[59-60]

[Image 172K] Technical drawing: R Register

[61; 62blank]

### APPENDIX F

### F Register Schematic

[63-64]

[Image 163K] Technical drawing: Bus Decode Board

[65; 66 blank]

### APPENDIX G

### Command/Status Board Schematic

[67-68]

[Image 160K] Technical drawing: Command Status Slave Decode

[69; 70 blank]

### APPENDIX H

### Watchdog Timer Board Schematic

[71-72]

[Image 156K] Technical drawing: Watchdog Decode

[73; 74 blank]

### APPENDIX I

### Mother Board Schematic

[75-76]

[Image 161K] Technical drawing: Authenticator Motherboard Decoder

[77; 78 blank]

### APPENDIX J

### Maintenance Support Board Schematic

[79-80]

[Image 118K] Technical drawing: 5V Only Maintenance Support Bd.

[81; 82 blank]

### APPENDIX K

### 32Kx8 EEPROM Board Schematic

[83-84]

[Image 150K] Technical drawing: Authenticator EEPROM Board

[85; 86 blank]

### APPENDIX L

### 64Kx8 EEPROM Board Schematic

[87-88]

[Image 131K] Technical drawing: 5V 64K Byte EEPROM

[89; 90 blank]

### APPENDIX M

### Bus Expansion Board Schematic

[91-92]

[Image 154K] Technical drawing: Fabrication Drawing Authenticator Buss Expansion

[93; 94blank]

### APPENDIX N

### External Bus Exerciser Schematic

[95-96]

[Image 93K] Technical drawing: Authentication External Bus Exerciser

[97; 98 blank]

### APPENDIX O

### VME Bus Interface Schematic

[99]

[Image 92K] Technical drawing: No title.

[100]

[Image 70K] Technical drawing: No title.

[101]

[Image 109K] Technical drawing: No title.

[102]

[Image 92K] Technical drawing: No title.

[103]

[Image 136K] Technical drawing: No title.

[104]

[Image 108K] Technical drawing: No title.

[105; 106 blank]

### APPENDIX P

### IBM PC/XT Bus Interface Schematic

[107-108]

[Image 210K] Technical drawing: Schematic Authenticator XT

[109]

### APPENDIX Q

### NSS Authenticator Addresses

[NSS Authenticator Addresses 12 K pages 110-122]

[123]

### APPENDIX R

### Message Formats and Protocol

[Message Formats and Protocol 26 K pages 124-144]

[145]

### APPENDIX S

### Test Source Code

[Test Source Code 57K pages 146-179; page 180 blank]

[181]

### APPENDIX T

### Benincasa's Algorithm Deficiencies

This draft memorandum was circulated at NSA. No final copy was required. Sandia Labs received one new algorithm.

[182]

                                    DRAFT

      June 21, 1989

      Dr. James J. Hearn
      Deputy Director for Information Security
      National Security Agency
      Fort &eorge G. Meade, MD 20755-6000

      Dear Dr. Hearn:

      The National Security Agency provided an approved data
      authentication algorithm for the SALT II seismic verification
      program in the middle 1970's.  It is called the National Seismic
      Station - Unmanned Seismic Observatory data authentication
      algorithm and is authored by Ronald Benincasa.

      The algorithm is currently being used for the Deployable Seismic
      Verification System.  Data rates increased so the NSS-USO
      algorithm implementation technology is upgraded.  The alogrithm
      continues to serve well for this particular program.

      We considered using this approved algorithm for other treaty
      verification programs but it has several major deficiencies which
      make it awkward to apply.

      These deficiencies are include:

          1.   The algorithm is bit oriented as opposed to byte, 16 bit
               word, 32 bit double word or 64 bit quad word oriented.

          2.   The algorithm requires stepping two of its internal
               registers at a rate many times the data rate.  This
               limits the maximum rate at which data can be
               authenticated.

          3.   The algorithm, because of deficiency 2, is only suitable
               for implementation in hardware.

          4.   The hardware implementation requires too much hardware
               using low technology chips releasable to treaty
               participants.  The device is too big and expensive.

          5.   The original algorithm specification was amended by
               NSA to handle resynchronization in event of data
               transmission errors.  It requires additional
               information to be added to a data frame to preserve
               adequate security.

                                   DRAFT

    [183]

                                   DRAFT

          6.   The algorithm is currently classified SECRET although
               its declassification to a level so its details can be
               given to the Soviet Union has been promised.

          7.   We expect to have data authentication applications with
               bilateral and multilateral treaties.  We feel it is
               advisable to use different algorithms for different
               treaties.

     We need a number of unclassified data authentication algorithms
     which which apply to different data widths and speeds.  The
     algorithms should permit inexpensive implementation in small
     packages.

     I ask that NSA assist us by providing us these algorithms.

     Sincerely,

     TBD by DOE

                                  DRAFT

     To:  Mark and Ed, R
     From: Bill   FAX 505-846-6652 phone 505-844-6847

     Tom read and approved this.  We wait for your comments.  When we
     all agree we'll forward this to Doug at DOE.

     cc Amy Johnston

[184]

DISTRIBUTION:

    2   Air Force Technical Applications Center    3   Lawrence Livermore National Laboratory,
        Att: F. Pilotte                                  L205
             G. Rothe                                  Att: D. Harris
        Patrick Air Force Base, FL 32925                    K. Nakanishi
                                                            S. Taylor
    1   University of New Mexico                       PO Box 808
        Att: Prof. N. Ahmed, Chairman                  Livermore, CA 94550
        Dept of Electrical & Computer Engineering
        Albuquerque, NM 87131                      2   University of New Mexico
                                                       Att: Dr. Donald R. Hush
    2   Center for Seismic Studies                          Prof. Neeraj Magotra
        Att: C. Romney                                 Dept. of Electrical & Computer Engineering
             S. Bratt                                  Albuquerque, NM 87131
        1300 N. 17th St., Ste 1450
        Arlington, VA 22209                        1   University of Central Florida
                                                       Att: Dr. Wasfy B. Mikhael
    1   Pacific-Sierra Research Corp.                  Electrical Engineering Dept.
        Att: Dr. A. P. Ciervo                          Orlando, FL 32816-0450
        12340 Santa Monica
        Los Angeles, CA 09925                      1   Kaman Sciences Corp.
                                                       Att: Kenneth Sabisch
    3   Defense Advanced Research Projects Agency      6400 Uptown Blvd. NE
        Nuclear Monitoring Research Office             Albuquerque, NM 87110
        Att: R. Alewine
             A. Kerr                               1   Science Applications International Corp.
             R. Blandford                              Att: T. Bache
        1400 Wilson Blvd.                              10210 Campus Point Rd.
        Arlington, VA 22209                            San Diego, CA 92121

    1   Prof. Delores M. Etter                     1   Arizona State University
        3167 Nelson Rd.                                Att: Prof. A. S. Spanias
        Longmont, CO 80503                             Dept. of Electrical & Computer Engineering
                                                       Tempe, AZ 85287-5706
    1   US Geological Survey
        Att: Dr. J. F. Everenden                   3   Teledyne Geotech
        345 Middlefield Rd.                            Att: O. Starkey
        Menlo Park, CA 94025                                O. D. Stanley
                                                            R. Bartholomew
    1   Southern Methodist University                  3401 Shiloh Rd.
        Att: Dr. Eugene Herrin                         Garland, TX 75040
        Institute for the Study of Earth and Man
        Geophysical Laboratory                     3   US Dept. of Energy
        Dallas, TX 75275                               Office of International Security Affairs
                                                       Att: D. Dowen
                                                            M. Koontz
                                                            D. Larson
                                                       Forrestal Bldg., DP-52
                                                       1000 Independence Ave. SW
                                                       Washington, DC 20585

    [185]

    DISTRIBUTION (Continued):

    2   USGS Albuquerque Seismological Laboratory  1   Atomic Weapon Research Establishment
        Att: C. R. Hutt                                Att: Dr. P. Marshall
             J. Peterson                               Blacknest
        Bldg. 10002, Kirtland AFB East                 Aldermaston, Berkshire
        Albuquerque, NM 87115                          UNITED KINGDOM

    2   Oregon State University                    2   NFNT/NORSAR
        Att: Dr. T. G. Lewis                           Att: S. Mykkeltveit
           Prof. T. G. Lewis                                F. Ringdal
        Computer Science Dept.                         PO Box 51
        Corvallis, OR 97331                            2007 Kjeller
                                                       NORWAY
    4   National Security Agency
        Att: Paul Bridge, U6                       1   700     G. J. Simmons
             Tom White, X431                       1   5000    R. L. Hagengruber
             Bruce Bottomly, S9                    1   5023    J. R. Wayland Jr.
             Mark Unkenholtz, R21                  5   5031    W. H. Payne
        9800 Savage Rd.                            1   9100    R. G. Clem
        Fort George G. Meade, MD 20755-6000        1   9123    J. Holovka
                                                   1   9236    P. B. Herrington
    1   Digital Computer Laboratory                1   9240    P. A. Stokes
        Att: Prof C. L. Liu                        1   9311    S. D. Stearns
        Computer Science Dept.                     1   8523-2  Central Technical Files
        1304 W. Springfield                        5   3141    S. A. Landenberger
        Champain-Urbana, IL 61801                  3   3151    G. C. Claycomb

    1   H. B. Durham
        420 S. Fleishauer Ln
        McMinnville, OR 97128

[End Report]

Hypertext by JYA/Urban Deadline.